SPEC-ERD-PRO · v0.2
27 June 2026
Owner: Platform team

Products & telemetry taxonomy — data model drill-down

The catalog behind every device: the commercial product line (family → model), the telemetry-schema registry each model declares, and the per-device resolver that connects a physical device to the exact shape of its telemetry. This is the section that makes device → product → telemetry structure a single, explicit chain.

1The chain at a glance

The former Device.Model free-text enum (frigo · koelkast · nevera) is gone. In its place, four entities turn "what is this device and how do I read its data?" into FK hops that never guess:

• ProductFamily → ProductModel — the commercial catalog. A family is a product line; a model is the sellable unit within it. Device.ModelKey and QuoteLine.ModelKey are FKs into ProductModel (DM-35).
• ProductModel declares a schema — each model carries a SchemaFamilyKey + DeclaredSchemaVersion: the telemetry shape the product is expected to emit (DM-36).
• TelemetrySchemaFamily — the flat registry of telemetry shapes, keyed independently of the commercial line. Refrigeration is family #1 (the existing 60-column schema); the others were discovered from the live fleet (DM-36).
• DeviceSchemaAssignment — the resolver. One row per classified device maps its IoT-Hub deviceId → (SchemaFamilyKey, ResolvedVersion) with a confidence score. The model declares; the assignment is ground truth (DM-37).

2The product line

The commercial taxonomy as it stands today — three families. Models and their declared schemas are the catalog's editable content; this table is illustrative of the current line, not a constraint (the live values live in the catalog).

Family	Class	Models	Declared schema family
frigo	edge micro data center	Frigo 20 · Frigo 30	refrigeration
koelkast	edge micro data center	Koelkast 20 · Koelkast 30	refrigeration
nevera	modular micro data center	nevera-30 · nevera-40	structured-15-digit

Nevera is a separate, newer product line from frigo/koelkast — and a different class: frigo and koelkast are edge micro data centers, nevera is the modular micro data center line. That newer line motivated a second telemetry shape and, with it, the whole multi-schema model (Initiative 015). The commercial family and the telemetry family are not 1:1: frigo + koelkast both speak refrigeration, while a new line can introduce a new shape.

3The telemetry-schema registry

The shapes discovered across the live fleet (Telemetry/Discovery · family-inventory.json). Each family is keyed independently, carries its own typed column set plus a JSONB escape hatch, and writes to its own per-family hypertable. Unknown patterns quarantine rather than drop (DM-38).

Schema family	Id pattern	Status	Notes
refrigeration (#1)	MDC-####	registered	the existing 60-column schema — Mod1 / Mod2 / Mod3 module sets
structured-15-digit	15-digit	registered	fixed-width structured id; next-gen line
dashed-4-segment	a-b-c-d	registered	four dash-separated segments
unknown-pattern	—	quarantine	unrecognized shape — held for a new registry entry, never dropped

4Conditions in play

The DM-rules that bind the taxonomy — rendered from the central catalog; the master holds the full set.

5Entity dictionary

Entity	Keys	Purpose / notable attributes
ProductFamily	Key	commercial product line — frigo · koelkast · nevera; class, cooling range, schema generation (DM-35)
ProductModel	Key · FK ProductFamilyKey	the single Product entity: the model within a family + its DECLARED telemetry schema (SchemaFamilyKey + DeclaredSchemaVersion), cooling capacity, series. Device.ModelKey / QuoteLine.ModelKey resolve here (DM-35, DM-36)
TelemetrySchemaFamily	Key	flat registry of telemetry shapes; id-pattern, current version, typed TelemetryFields + count, TwinFields, per-family StorageTarget, status (registered · quarantine) (DM-36, DM-38)
DeviceSchemaAssignment	DeviceId · FK SchemaFamilyKey	per-device resolver keyed by IoT-Hub deviceId → ResolvedVersion + Confidence; status resolved · review · quarantine (DM-37)
Device	Id (MDC-####) · FK ModelKey	ModelKey → ProductModel (was a Model enum, v0.21); site, customer org, commissioned

6Open modeling questions

• Schema-family granularity — a family is keyed flat today, mapped to models. If a single model ever emits two shapes (per generation / module-set), the model→family link becomes 1:many and DeviceSchemaAssignment, not ProductModel, becomes the only reliable source. (Initiative 015)
• Declared vs. resolved drift — when a device's resolved family disagrees with its model's declared family, which wins, and is the mismatch an alert? Decides whether DeviceSchemaAssignment needs a "diverged" status beyond review/quarantine. (new — found modeling DM-37)
• Version migration — a schema-version bump is additive today; does superseding a version need a back-fill record per device, or is ResolvedVersion enough? (PRO-6, shares the PTL-1 time-series gap)

7Revision history

Version	Date	Changes
0.1	27 Jun 2026	First drill-down — split out of SPEC-ERD v0.21. The device model becomes an entity: ProductFamily · ProductModel · TelemetrySchemaFamily · DeviceSchemaAssignment; the taxonomy diagram, DM-35…38 and the PRO-1…6 requirements. Realizes Initiative 015 + discovery epics 078–080.
0.2	27 Jun 2026	Authoritative product classification. Families gain their class: frigo & koelkast = edge micro data center, nevera = modular micro data center; models set to frigo-20 · frigo-30 · koelkast-20 · koelkast-30 · nevera-30 · nevera-40 (replaces the earlier illustrative numbers). ⚠ frigo's second model read as frigo-30 (source listed “frigo-20” twice) — confirm.